OKF：LLM Wiki 知识库的落地实践标准

极客工具极客工具 XTool 2026年6月17日 22:41

你花三个月做了技术调研，读了二十篇论文、整理了十几份文档、记了一百多条笔记。结论有了，关键词也有。但当你问 AI：「这个技术领域的核心概念是什么？不同方案的权衡是什么？」

它答不上来。

不是因为你笔记写得不好，而是因为这些笔记缺乏结构 ——AI 不知道「这篇是方法 A 的缺陷分析，那篇是方法 B 的适用场景，另外几篇是竞品对比」，它只能看到一堆文本，不知道它们之间的关系。

Karpathy 的 LLM Wiki 思路给了一个方向：采集 → 整理 → 生成可查询的 wiki。但真正落地时你会发现一堆问题没有答案：frontmatter 应该有哪些字段？目录怎么组织？AI 按什么路径找知识？这些没有标准答案，大家都在模糊地试。

OKF（Open Knowledge Format） 补上了这一环。

OKF 是什么

OKF 是 Google Cloud 在 2026 年初发布的 知识表示格式规范 。本质上，它是一组约定：如何用 Markdown 文件组织知识，使得知识结构——有哪些概念、各概念之间什么关系、AI 怎么找到它们——变得机器可读。

规范极度轻量，只有三条原则：

最小化偏见 — 只强制要求一个字段： type 。其他字段全部由你自己定义。

生产者 / 消费者独立 — Google 给了一套从 BigQuery 自动生成 Bundle 的工具，但你可以手写、用任意工具生成。规范只是约定，不是绑定。

格式不绑定平台 — OKF Bundle 就是一个文件夹，里面是一堆 .md 文件。Git 管理、打包成 tarball、直接拷贝——没有任何专有依赖。

OKF 回答了落地问题 ：header 写什么（ type 必填，其他自定义）、数据怎么组织（index.md + 分类目录 + references）、AI 怎么找（从 index.md 开始，按链接逐层读取）。

OKF 和 PKM 已有实践的对应关系

如果你已经在用 Obsidian，看到 OKF 的结构会觉得眼熟——它们的思路高度重合，只是表述不同：

OKF 概念	PKM 对应	说明
`index.md`	MOC（Map of Content）	入口导航页，列出该领域的核心页面
目录分层结构	PARA / 主题文件夹	按领域组织，不是扁平文件列表
frontmatter `type`	页面类型标签（Concept / Note / Reference）	定义这篇笔记是什么类型的知识
references	双向链接 `[wikilink](/wiki/wikilink)`	概念之间的关联
`type: Reference`	Literature Note	引用来源

OKF 把这些做法标准化了，并且配套了工具链。但如果你已经在用 Obsidian， 你其实已经在实践 OKF 的思路了 ——只是没有意识到这和 Google 提出的规范是同一件事。

一个关键分类：Skill 和 OKF 解决不同问题

在 AI Agent 的语境里，这两个概念经常被混在一起，但解决的是完全不同的问题：

• Skill = 程序性知识，回答「怎么做」
• OKF = Declarative 知识，回答「是什么」以及「知识在哪里」

技术调研场景下：OKF 负责告诉 AI「方法 A 是什么、适用场景是什么、和方法 B 的核心差异是什么」；Skill 负责「用方法 A 写一段示例代码、用 pip 安装这个包」。两者各司其职。

这和 CoALA 框架也是一致的：

• 程序性记忆 ：怎么做（Skill）
• 语义记忆 ：是什么、在哪里（OKF）
• 情景记忆 ：发生了什么（Chat History / Daily Notes）

OKF vs RAG：不是替代，是分工

	RAG	OKF
本质	检索技术	知识表示格式
知识组织	非结构化 Chunk，向量索引	结构化图谱，预先定义关联
查询方式	语义相似度搜索	精确路由（读索引 → 读概念 → 读详情）
维护成本	低，追加文档即可	高，需要同步更新
适用场景	变化频繁的非结构化知识	相对稳定、有明确 Schema 的领域

• RAG = 搜索引擎。输入「Vue 响应式原理」，返回一堆包含这些词的网页。
• OKF = 翻目录。你翻开《Vue 权威指南》的目录，直接翻到「响应式原理」那一章。

更合理的组合是： 用 OKF 定义知识边界和关联，让 AI 先确定查哪个库；再用 RAG 在具体库内做语义搜索。

enrichment_agent 工具链

OKF 官方提供了一套参考实现工具 enrichment_agent ，基于 Google ADK（Agent Development Kit）构建，包含两个 AI Agent：

Agent	能力
`build_bq_agent`	读取 BigQuery 表结构，自动生成 metrics + joins
`build_web_agent`	抓取官方文档，生成对应的 reference 文档

背后默认用 gemini-flash-latest ——整个生成过程是 AI 密集型的，不是硬编码规则。

生成完 Markdown 文件后， writer.py 把所有内容打包进 viz.html ——一个自包含的交互图谱，用 Cytoscape.js 渲染节点关系，点击节点可以看到完整文档。

最终交付两个产物： 人类可读的 Markdown 文件 （可版本控制）+ AI 可消费的 BUNDLE 对象 （JSON 结构，大模型直接读取做推理）。

viz.html 图谱：实际效果

OKF 官方提供的 viz.html 用 Cytoscape.js 渲染成交互式图谱。以下是 GA4 Bundle 的实际运行效果：

点击任意节点，右侧面板会显示该概念的完整文档内容，包括 frontmatter 元数据和 Markdown body：

支持按类型过滤节点、快速搜索、以及查看每个节点的「Cited by」反向引用：

有意思的是细节： OKF 用标准 Markdown 链接 [text](path.md) ，Obsidian 用双向链接 [wikilink](/wiki/wikilink) 。如果你把 OKF Bundle 直接丢进 Obsidian，graph 视图是空的——Obsidian 只识别 [[]] 语法。目前两者没有很好的兼容方案。

Bundle 结构：知识如何分层组织

一个 OKF Bundle 本质上是一个目录，包含某个知识领域的完整文档：

ga4/
├── index.md                 # 入口（MOC 导航页）
├── datasets/
│   └── ga4_obfuscated_sample_ecommerce.md
├── tables/
│   └── events_.md
└── references/
    ├── metrics/
    │   ├── event_count.md
    │   └── user_count.md
    └── joins/
        └── events___ads_clickstats.md

每个 .md 文件的结构： YAML frontmatter + Markdown body 。

---
type: BigQuery Table
title: Events table
description: 包含 Google Analytics 事件导出数据
resource: https://bigquery.googleapis.com/...
tags: [events, Google Analytics, BigQuery]
---

body 分层写入：Overview → Schema → Metrics → Joins → Citations。

对个人知识库的启发

OKF 的价值不是让你迁移到一套新系统，而是让你重新审视几个已经存在的实践：

MOC 是入口，不是装饰 — MOC 的本质是路由 ——告诉 AI 或其他人「这个领域的知识从哪里开始、核心是哪几篇」。写得好的 MOC 应该能让人在三分钟内搞清楚这个领域的结构。

frontmatter 的 type 字段值得认真填 — OKF 只强制要求 type ，这是有道理的。类型标签是机器理解一篇笔记「是什么」的最直接路径。

References 是双向的 — A 引用了 B，B 应该能列出「被谁引用」。OKF 的 viz.html 在每个节点详情里显示了「Cited by」。Obsidian 的反向链接面板本质上做了同一件事——但很多人没有认真用过它。

知识库也需要「新陈代谢」 — OKF Bundle 的结构适合稳定领域，但现实中的知识库是不断生长的。定期 review、淘汰过时内容、合并重复概念——比一味新增更重要。

OKF 规范地址 ：https://github.com/GoogleCloudPlatform/knowledge-catalog

前沿工具 · 目录

继续滑动看下一个

极客工具 XTool

向上滑动看下一个